In modern relational database management systems (RDBMS), modifications to the database are logged into a redo stream made up of redo records. This redo stream can be used to service log-mining and other applications so as to provide a variety of functionality. For example, the redo stream can be used to construct a standby database, in which a standby database shadows a primary database by extracting committed transactions out of the redo stream and “redo-ing” or otherwise applying those transactions to a standby instance. As another example, the redo stream can be used to provide log-based replication, in which a replica site extracts committed changes made to the tables of interest in the database and applies the changes to the replica in order to keep the replica tables synchronized. As yet another example, the redo stream can be used to provide user query functionality, in which the redo stream is queried as though it were a relational database.
In many cases, in order to interpret a redo record (e.g., change records), a data dictionary is needed. Over time, a database undergoes changes (e.g., resulting from an operation to add a column to a table, or to change a data format, etc.) and such changes are captured in a redo log. For example, a redo log might capture all data definition commands as well as all data manipulation commands from the period January 1 through March 30. In order to process the full range of log mining queries that pertain to the database contents as of February 14, the data dictionary that was then-current as of February 14 would need to be constructed.
A data dictionary can be constructed by determining an initial state of the database (e.g., as was then-current as of a moment just prior to a redo log entry) and then applying the exact sequence of redo log entries through to at least the February 14 time marker in the redo log. In this manner, a data dictionary can be generated and then used to process log mining queries that pertain to particular database object contents as of February 14. Using the same redo log, a fully completed data dictionary can be generated to cover all objects in the database over all time covered by the redo log. Such a complete data dictionary can in turn be used to process the full range of log mining queries that pertain to the database contents through the full range of dates that bound the redo log.
Unfortunately, the processing time (e.g., latency) needed to read in an initial state of a subject database and to then apply the exact sequence of redo log entries from the tine of the initial state through to a particular moment in time can become long, especially in situations when the redo log is especially large, or has an especially large number of database objects and/or when a large number of redo log entries are to be applied. The latency experienced by the log-mining user before the log-mining user can receive results of a first query can be long. Techniques are needed to reduce this latency.
What is needed is a technique or techniques to improve over legacy and/or over other considered approaches. Some of the approaches described in this background section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.